Addresses #195.
Depends on parallel driver PR134: jhedstrom/DrupalDriver#134.

A few architectural notes ...

Service architecture

I had in mind the possibility that there could be fundamentally different mechanisms for handling test emails (e.g. Drupal core's test mail collector, contrib maillog, and IMAP) which could use the same context. Therefore I tried to put interacting with the mail store outside of the context as a service. The supplied implementation uses test mail collector.

However, I'm not clear yet on how do this in the Drupal extension and so it's not a real service for now, just a kind of service-like class. Hopefully though it will be relatively easy to upgrade to a real service in the future.

Abstracting in this way is responsible for a few minor complications that have no purpose in the default implementation such as

• the distinction between enabling/disabling email sending, and collecting/not-collecting emails. An IMAP service would want to send emails AND collect them, whereas for Drupal's test mail collector collecting always stops sending.
• the $store name passed when getting emails. Test mail collector is just one store, but different services, or combinations of services, could potentially be capturing emails into various different stores.

Mink context

I needed to be able to visit pages in order to follow links from emails, but the context is extending RawDrupalContext not RawMinkContext. Therefore I moved getcontext() out of SubContextBase into it's parent RawDrupalContext and used this to help me load a minkContext and visit a page. Maybe there was an easier way of doing this.